Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check for Component ID count exceeding 32 to prevent memory corruption in application firmware #23

Open
wants to merge 1 commit into
base: release
Choose a base branch
from

Conversation

udbhav-s
Copy link

The flash_entry struct type in application_processor.c is used for saving information about provisioned components to flash memory. On the first initialization of the application board it creates an array of all the provisioned components from the header file and uses memcpy to copy it to flash_status, which is then written to flash.

The component_ids field of flash_entry is an array of 32 IDs - however, the build tools place no restriction on the number of component IDs that are passed in the arguments. If more than 32 component IDs are passed during the build AP step, the memcpy will write past the struct, corrupting the application's memory and breaking functionality.

We're assuming that an application firmware should be able to support more than two components because the detailed specifications do not mention a component count limit for an AP, and the scan_components method in the reference design loops through all 127 valid I2C addresses (except reserved ones) to check for the presence of components.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant